-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manager subview components #884
Conversation
d7f447e
to
954062f
Compare
Ready for review now. The broken link will be fixed in the next PR, which should be merged at the same time. |
e7f95e1
to
b6a8d07
Compare
954062f
to
0e014ea
Compare
0e014ea
to
6202516
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes are good on a high level and wasn't able to spot anything obviously wrong with them. I only wish GitHub was able to show moved (but identical) code easier to make reviews for refactors like this a bit easier.
6202516
to
a9d3db9
Compare
Fixed this line to use |
The idea is that the selected subview will later be selected automatically by the routing component, but for this to work the view pretty much needs to be a single component. The commit actually contains a broken link for moving between the subviews. I didn't want to waste energy solving that since it would be overwritten by a future commit anyway. Since the component will be defined in the routing config in the future it made sense to me that the component is imported directly rather than via a provider. To my understanding the point of the providers is to allow swapping components for customization, and in the future that will be handled by the router config. Refs TS-1310
Instead of passing the filtering function as a prop to the modal that handles updating filter values, watch changes to those values instead. This makes it easier to move the filtering function to another module in the future. As a side effect of this change, the mod list is now updated immediately when a filter is changed. Keen eyes can detect the mod list updating under the modal. I didn't detect any performance issues with this approach, but if problems arises with this approach, we can change the modal to store the changes to filters locally and commit them to Vuex store only when the modal is closed. Instead of calling the method responsible for sorting the mod list (which calls the filtering method behind the scenes), call the filtering method directly. Changes done in the filter modal don't affect the sorting, so sorting the list seems unnecessary. Refs TS-1311
The idea is that the selected subview will later be selected automatically by the routing component, but for this to work the view pretty much needs to be a single component. Since the component will be defined in the routing config in the future it made sense to me that the component is imported directly rather than via a provider. To my understanding the point of the providers is to allow swapping components for customization, and in the future that will be handled by the router config. Refs TS-1311
a9d3db9
to
b857235
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Draft PR since it contains a broken link and I haven't tested this properly yet. Wanted to put this out here in case there's some reviews going on during the weekend, as feedback is very welcome.